Subject: Defer-Receive State

From: "Jack Sanders" <[email-masked]>
Date: Fri, 11 Mar 94 15:14:30 EST

Ref:  E-mail from Uwe Goellner, same subject, 3/10/94, appended below

Uwe,

See my comments below, indicated by >.

Best regards,
Jack
-----------------------Appended Note--------------------------
There are some state transitions concerning the Defer-Receive State (9)
which, to us, seem to be wrong:

A local TP in Send state (3) issuing a CMPTR call with
prepare_to_receive_type set to CM_PREP_TO_RECEIVE_SYNC_LEVEL and
sync_level = CM_SYNC_POINT changes it's state to Defer-Receive (9) but
still has send control, see the usage notes for CMPTR.

Due to these usage notes and the state table in appendix C, the local TP
transfers the send control to the remote TP and enters Receive state (4)
when it issues a CMFLUS or CMCFM call.

1) This behaviour of CMFLUS and CMCFM differs from the behaviour of those
   calls when issued in the "normal" Send state, where send control is not
   transferred to the partner TP (except for the CMCFMD). To us there is
   no reason for this difference.

>  The reason for the difference is that the program issued a
>  CMPTR call so that the CRM would transfer send control to the
>  partner when a subsequent CMFLUS, CMCFM, or commit call is issued.
>  A program should not issue CMPTR until it is ready for send
>  control to be transferred as a result of the subsequent call.

2) Does the remote TP receive a status_received = CM_SEND_RECEIVED as a
   result of the CMFLUS ?

>  Yes.  The CMFLUS call in Defer-Receive state should result in
>  a TP-GRANT-CONTROL request.  The mapping of CPI-C to OSI TP will be
>  fixed to indicate this.

3) Most important objection to this behaviour:
   in OSI-TP there is no state change when the local application sends the
   TP-DEFERRED-GRANT-CONTROL-req (which corresponds to the CMPTR). Thus
   the application remains in Send state and also does not transfer
   send control to the partner application when it sends a TP-HANDSHAKE-req
   (which corresponds to the CMCFM), except perhaps to receive the confirm.
   Running CPI-C on an OSI-TP CRM, this results in an inconsistency between
   the CPI-C state and the corresponding OSI-TP state.

>  A CMCFM call in Defer-Receive state should result in a
>  TP-HANDSHAKE-AND-GRANT-CONTROL request.  The mapping will be fixed
>  to indicate this.

To avoid these inconveniences we suggest to change the CPI-C state table
in such a way, that send control will NOT be transferred to the partner
if CMFLUS or CMCFM are issued in Defer-Receive state,

>  This change would cause problems with existing programs.  It is
>  important that existing programs continue to run as CPI-C is enhanced.

or, perhaps still
better, to skip that state totally and rather remember the fact that a
CMPTR with CM_PREP_TO_RECEIVE_SYNC_LEVEL was sent in a new
characteristic.

>  A CPI-C implementation can remember that a CMPTR(S_L) was issued in
>  any convenient way.  When a subsequent call is issued,
>  the implementation must take the right action depending on
>  the state as viewed by the program at the CPI-C interface.

An other point: did you receive our mail from the 3rd of March concerning
the problems of using CPI-C together with TX ?  We did not receive any
comments on that yet.

>  The mail was received by the OSI TP SIG.  A separate comment will be
>  forthcoming.

    Best regards
      Uwe

-----------------------------------------------------------------------------
Uwe Goellner                         |   Tel.:  07531-87-4628
Computer Gesellschaft Konstanz mbH   |   Fax:   07531-87-4888
Max-Stromeyer-Strasse 116            |   Email: [email-masked]
78467 Konstanz                       |
Germany                              |
=============================================================================